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Background 



□ Lineage 

■ Thesis work at MIT building a new OS (exokernel) 

■ Spent last 7 years developing methods to find bugs in 
them (and anything else big and interesting) 

□ Goal: find as many serious bugs as possible. 

■ Agnostic on technique: system-specific static analysis, 
implementation-level model checking, symbolic execution. 

■ Our only religion: results. Works? Good. No work? Bad. 

□ This talk 

■ eXplode: model-checking to find storage system bugs. 

■ EXE: symbolic execution to generate inputs of death 

■ Maybe: weird things that happen(ed) when academics try 
to commercialize static checking. 
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The problem 

□ Many storage systems, one main contract 

■ You give it data. It does not lose or corrupt data. 

■ File systems, RAID, databases, version control, ... 

■ Simple interface, difficult implementation: failure 

□ Wonderful tension for bug finding 

■ Some of the most serious errors possible. 

■ Very difficult to test: system must *always* 
recover to a valid state after any crash 

■ Typical: inspection (erratic), bug reports (users 

Goafedftc|f^ 

systems with little work 



explode summary 



□ Comprehensive: uses ideas from model checking 

□ Fast, easy 

■ Check new storage system: 200 lines of C++ code 

■ Port to new OS'. 1 device driver + optional instrumentation 

□ General, real: check live systems. 

■ Can run (on Linux, BSD), can check, even w/o source code 

□ Effective 

■ checked 10 Linux FS, 3 version control software, Berkeley DB, 
Linux RAID, NFS, VMware &SX 3.2/Linux 

■ Bugs in all, 36 in total, mostly data loss 
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Checking complicated stacks 



□ All real 

□ Stack of storage 
systems 

■ subversion: an 
open-source 
version control 
software 

□ User-written 
checker on top 

□ Recovery tools run 
after EXPLODE- 
simulated crashes 
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%mdadm —assemble 

—run 
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— update=resync 
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Outline 



Core idea 



□ Checking interface 



□ Implementation 



□ Results 



□ Related work, conclusion and future work 



The two core eXplode principles 

□ Expose all choice: 

When execution reaches a point in program that can do 
one of N different actions, fork execution and in first 
child rlo first action, in spcond rlo spconrl, ptc 

□ Exhaust states; 



Do every possible action to a state before exploring 
mother. 



□ Result of systematic state exhaustion: 

■ Makes low-probability events as common as high- 
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Core idea: explore all choices 

□ Bugs are often triggered by corner cases 

□ How to find: drive execution down to these 
tricky corner cases 

When execution reaches a point in program that can do 
one of N different actions, fork execution and in first 
child rlo f irst action, in spcnnrl rlo spconrl, ptc, 



External choices 



□ Fork and do every possible operation 




Explore generated 
states as well 



Speed hack: hash states, discard if seen, 
prioritize interesting ones. 



Internal choices 

□ Fork and explore all internal choices 




kmalloc returns NULL 



Buffer cache misses 



How to expose choices 

□ To explore N-choice point, users instrument 
code using choose(N) 



□ choose(N): N-way fork, return K \n K'th kid 
void* kmalloc(size s) { 
if(choose(2) ==0) 
return NULL; 

... // normal memory allocation 

} 



□ We instrumented 7 kernel functions in Linux 



Crashes 



□ Dirty blocks can be written in any order, crash 
at any point 



/root 
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buffer 
cache 




Write all 
subsets 



Users write code to 
check recovered FS 




f sck ~* check 



f sck ~* check 



f sck ~* check 




Outline 

□ Core idea: exhaustively do all verbs to a state. 

■ external choices X internal choices X crashes. 

■ This is the main thing we'd take from model checking 

■ Surprised when don't find errors. 



Checking interface 

- What EXPLODE provides 

■ What users do to check their storage system 



□ Implementation 



□ Results 



□ Related work, conclusion and future work 



What EXPLODE provides 

□ choose(N): conceptual N-way fork, return K in 
K'th child execution 



□ check_crash_now(): check all crashes that 
can happen at the current moment 

■ Paper talks about more ways for checking crashes 

■ Users embed non-crash checks in their code. 
EXPLODE amplifies them 

□ errorQ: record trace for deterministic replay 



What users do 



□ Example: ext3 on RAID 



FS checker 



Ext3 
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□ checker: drive ext3 to do something: mutate(), 
then verify what ext3 did was correct: checkQ 



□ storage component: set up, repair and tear down 
ext3, RAID. Write once per system 



■ i 



■ * 



□ FS Checker 

■ mutate 



□ ext3 
Component 



□ 



const char *dir = "/mnt/sbdO/"; 
const char *file = "/mnt/sbdO/test-f ile"; 
void FsChecker::mu tate(void) { 
i w itch (choose (4)] { 



s^ o n- oyo t Q m f("or>in ^Uest\" > %s", file); 
if [choose(2)1 == 0) 

sy iC v/ ; 
elsel{ 

dojfeync(file): 

// fsync parent to commit the new directory entry 

do_f sync( " /rant /sbdO " ) ; 



eck_crash_now(); // invokes checkQ for each crash 



} 



jak; 

ca& t; ji^ systemf( " i m "i '' HM break; 

cnir\^- """tnmff"m1'fiiT SiajWP^T dir, |choose(5)D ; break; 

case 3s„systemt ( " rmdir °/„3/U' T dir, |choose(b)| >; break; 

} 



choose(4) 




creat file rm file 



sync fsync 
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□ FS Checker 

■ check 



□ ext3 
Component 



□ 



Check file exists 



void FsChecker::check(void) { 
ifstream in(file); 
if(!in) 

error("fs", "file gone!"); 
char buf[1024]; 
in.read(buf, sizeof buf); 
in.close(); 



Check file 
contents match 



} 



if(strncmp(buf, "test", 4) != 0) 

error("fs'\ "wrong file contents!"); 



Even trivial checkers work:finds JFS 
fsync bug which causes lost file. 

Checkers can be simple (50 lines) or 
very complex(5,000 lines) 

Whatever you can express in C++, you 
can check 



□ 



□ ext3 
Component 



□ 



□ storage component: initialize, 
repair, set up, and tear down your 
system 

■ Mostly wrappers to existing utilities, 
"mkfs", u f sck", "mount", "umount" 

■ threads(): returns list of kernel 
thread IDs for deterministic error 
replay 



□ Write once per system, reuse to 
form stacks 



□ Real code on next slide 



□ 



□ ext3 
Component 



□ 



void Ext3::init(void) { 

// ornate an empty extS FS with 
// user-specified block size 
systemf("mkf s . ext3 -F -j -b %d %s", 
get_option(blk_size), children [0]— >path()); 

} _ 

void Ext3::recover() { 

systemf("f sck.ext3 -y %s", children[0]— >path()) 

} m 

void Ext3:: mount (void) { 

int ret = systemf("sudo mount -t ext3 °/ s c / s", 

children [0]— >path(), path()); 
if(ret < 0) error ("Corrupt FS: Can't mount!"); 

} _ 

void Ext3::umount(void) { 
systemf("sudo umount °/ s", pathQ); 

} m 

void Ext3::threads(threads_t <^thids) { 
int thid; 
if((thid=get_pid("kjournald")) != -1) 

thids.push_back(thid); 
else 

explode- panic(" can't get kjournald pid!"); 

} 



□ 



□ ext3 
Component 



t3 



□ Stack 

Raid 









RAM Disk 
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□ assemble a checking stack 



□ Let EXPLODE know how 
subsystems are connected 
together, so it can initialize, set 
up, tear down, and repair the 
entire stack 



□ Real code on next slide 



□ 



□ ext3 
Component 



t3 



□ Stack 

Raid 









RAM Disk 
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RAM Disk 



Assemble FS -f RAID storage stack step by step. 
void assemble(Component *&top, Test Driver *&driver) { 
// 1. load two RAM disks with size specified by user 
ekm_load_rdd(2, get_option(rdd, sectors)); 
Disk *dl = new Disk("/dev/rddO M ); 
Disk *d2 = new Disk("/dev/rddl"); 

// 2. plug a mirrored RAID array onto the two RAM disks. 
Raid *raid = new Raid("/dev/mdO" T "raidl"); 
raid— >plug_child(dl); 
raid— >plug_child(d2); 



3. plug an extS system onto RAID 
Ext3 *ext3 = new ExtSO'/mnt/sbdO"); 
ext3— >plug_child(raid); 
top = ext3; // let eXplode know the top of storage stack 



} 



4- attach a file system test driver onto extS layer 
driver = new FsChecker(ext3); 



Outline 



□ Core idea: explore all choices 



□ Checking interface: 200 lines of C++ to check a system 



Implementation 

Checkpoint and restore states 

Deterministic replay 

Checking process 

Checking crashes 

Checking "soft" application crashes 

□ Results 



Recall: core idea 



□ "Fork" at decision point to explore all choices 

state: a snapshot of 
the checked system 




How to checkpoint live system? 



□ Hard to checkpoint live 
kernel memory 

■ VM checkpoint heavy-weight 

□ checkpoint: record all 
chooseQ returns from SO 



□ restore: umount, restore 
SO, re-run code, make K'th 
choose() return K'th 
recorded values 




S = SO + redo choices (2, 3) 



. *. > . 



Deterministic replay 

□ Need it to recreate states, diagnose bugs 

Sources of non-determinism 

□ Kernel choose() can be called by other code 

■ Fix: filter by thread IDs. No choose() in interrupt 

□ Kernel scheduler can schedule any thread 

■ Opportunistic hack: setting priorities. Worked well 

■ Can't use lock: deadlock. A holds lock, then yield to B 

□ Other requirements in paper 



□ Worst case: non-repeatable error. Automatic 
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EXPLODE: put it all together 




EXPLODE 



User code EKM = EXPLODE 

device driver 



Outline 

□ Core idea: explore all choices 

□ Checking interface: 200 lines of C++ to check a 
system 

□ Implementation 



□ Results 

■ Lines of code 

■ Errors found 



i • i r 



EXPLODE core lines of code 







Lines of code 


Kernel patch 


Linux 


fl,915\+Cl94 generated)} 


FreeBSD 


Q>210) 


User-level code 


f6323J 



3 kernels: Linux 2.6.11, 2.6.15, FreeBSD 6.0. 
FreeBSD patch doesn't have all functionality yet 



Checkers lines of code, errors found 




Storage System Checked 
10 file systems} 



Component 



Outline 

□ Core idea: explore all choices 

□ Checking interface: 200 lines of C++ to check 
new storage system 

□ Implementation 

□ R esults 

* Lines of code 
■ Errors found 



i • i r 



FS Sync checking results 



FS 


sync 


mount sync 


f S^TIC 


O.SYNC 


ext2 




X 


® 


X 


ext3 






^^■^ 


X 


ReiserFS 




X 




X 


Reiser4 








X 


JFS 
XFS 




X 
X 


® 


X 
X 


MSDOS 


X 


X 




X 


VFAT 


X 


X 




X 


HFS 


X 


X 


X 


X 


HFS+ 


X 


X 


X 


X 



X indicates a failed check 

App rely on sync operations, yet they are broken 



ext2 f sync bug 



Events to trigger bug 

truncate A 
creat B 



write B 
fsync B 

crash! 

fsck.ext2 



A 



Mem 



Disk 



A 



Indirect block 
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Bug is fundamental due to ext2 asynchrony 



Classic* mishandle crash during recovery 

□ ext3, JFS, reiserfs: All had this bug 

■ Result: can lose directories (e.g., V") 

■ Root cause: the same journal ling mistake. 

□ To do a file system operation: 

■ Record effects of operation in log ("intent") 

■ Apply operation to in-memory copy of FS data 

■ Flush log (so know how tofix^a*HdfStr3a^). wait() 

■ Flush data. 

■ All get this right. 

□ To recover after crash 

■ Replaylbg^o fix FS. Flush FS changes to disk. 

■ waitQ ^ 



ext3 Recovery Bug 



recover_ext3_journal(...) { 

retval = -journal_recover(journal) 

//... 

// clear the journal 

e2fsckJournal_release(. . .) 

//... 

} 




jomnal_recover(...) { 
// replay the journal 
//... 

// sync modifications to disk 
fsync_no_super (...) 

} 



// Error! Empty macro, doesn't sync data! 
#define fsync_no_super(dev) do { } while (0) 




□ Code was directly adapted from the kernel 

□ But, fsync_no_super was defined as NOP 



Easy checking of "transparent 11 

subsystems 

□ Many subsystems intend to invisibly augment storage 

■ Easy checking: checker run with and without = equivalent. 

■ Sync-checker on NFS, RAID or VMM should be same as not 

■ Ran it. All are broken. 

□ Linux RAID: 

■ Does not reconstruct bad sectors: marks disk as faulty, 
removes from RAID, returns error. 

■ Two bad sectors, two disks: almost all reconstruct fail 

□ NFS: 

■ write file, then read through hardlink = different result. 

□ GSX/Linux: 



Even simple test drivers find bugs 

□ Version control: cvs, subversion, "ExPENsive" 

■ Test: create repository with single file, checkout, modify, 
commit, use eXplode to crash. 

■ All do careful atomic rename, but don't do fsync! 

■ Result: all lose commited data. Bonus: crash during 
"exPENsive" merge = completely wasted repo 

□ BerkeleyDB: 

■ Test: loop does transaction, choose() to abort or commit. 

■ After crash: all (and only) commited transactions in DB. 

■ Result: commited get lost on ext2, crash on ext3 can leave 
DB in unrecoverable state, uncommited can appear after 



Classic app mistake: "atomic" rename 

□ All three version control app. made this mistake 



□ Atomically update file A to avoid corruption 

fd = creat(A_tmp, ...); 
write(fd, ...); 
fsync(fd); // missing! 
close(fd); 
rename(A_tmp, A); 



□ Problem: rename guarantees nothing abt. Data 



Outline 

□ Core idea: explore all choices 

□ Checking interface: 200 lines of C++ to check a 
system 

□ Implementation 

□ Results: checked many systems, found many 
bugs 



□ Related work, conclusion and future work 



Related work 



□ FS testing 
- IRON 



□ Static analysis 

■ Traditional software model checking 

■ Theorem proving 

■ Other techniques 



Conclusion and future work 

□ EXPLODE 

■ Easy: need 1 device driver, simple user interface 

■ General: can run, can check, without source 

■ Effective: checked many systems, 36 bugs 

□ Current work: 

■ Making eXplode open source 

■ Junf eng on academic job market. 

□ Future work: 

■ Work closely with storage system implemented to check 
more systems and more properties 

■ Smart search 

■ Automatic diagnosis 

■ Automatically inferring "choice points" 

■ Approach is general, applicable to distributed systems, 
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Trend: mount untrusted disks 



> Software Distribution: Distributing Software With Inte <Q |_WN: Patch: [PATCH] unprivileged mount/umount - Mozilla Firefox 
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Patch: [PATCH] unprivileged mount/umount 

Fiom: Miklos Szeredi <miklos@szeredi.hu> 

To: linux-fs de vel@vger. kernel. org, linux-kernel@vger. kernel. org 

Subject; [RCF] [PATCH] unprivileged mount/urnount 

Date; Tue, 03 May 2005 16:31:35 +0200 

Cc; ericvh@gmail.com, smfrench@austin.rr.com, hch@infradead.org 

Archive-link Article, Thread 

This (lightly tested) patch against 2.6.12— re* adds sortie 
infrastructure and basic functionality for unprivileged mount/umount 
system calls. 

Details : 

- new mnt_owner field in struct vfsmount 

- if mnt_owner is NULL, it's a privileged mount 

- global limit on unprivileged mounts in /proc/sys/f s/mount-max 

- per user limit of mounts in rlimit 

- allow umount for the owner (except force flag) 

- allow unprivileged bind mount to files/directories writable by owner 

- add nosuid,nodev flags to unprivileged mounts 

Wext step would be to add some policy for new mounts. I'm thinking of 
either something static: e.g. FS_SAFE flag for "safe" filesystems, or 
a more configurable approach through sysfs or something. 
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File systems vulnerable to malicious disks 



Privileged, run in kernel 

Not designed to handle malicious disks. 
FS folks not paranoid (v.s. networking) 

Complex structures (40 if statements in 
ext2 mount) ■*• many corner cases. 
Hard to sanitize, test 

Result: easy exploits 



Generated disk of death 

(JFS, Linux 2.4.19, 2.4.27, 2.6.10) 



Offset 


Hex Values 


00000 


0000 0000 0000 0000 0000 0000 0000 0000 


+ * * 


« * * 


08000 


464a 3153 0000 0000 0000 0000 0000 0000 


08010 


1000 0000 0000 0000 0000 0000 0000 0000 


08020 


0000 0000 0100 0000 0000 0000 0000 0000 


08030 


e004 OOOf 0000 0000 0002 0000 0000 0000 


08040 


0000 0000 0000 0000 0000 0000 0000 0000 


* * * 


• * * 


10000 





Create 64K file, set 64 th sector to above. Mount. 
And PANIC your kernel! 




FS security holes are hard to test 



Manual audit/test: labor, miss errors© 
Random test: automatic©, can't go far© 

■ Unlikely to hit narrow input range. 

■ Blind to structures 



int fake_mount(char* disk) { 
struct super_block *sb = disk; 
if(sb->magic != OxEF53) //hard to pass using random 

return -1; 
// sb->foo Is unsigned, therefore >= 
if(sb->foo > 8192) 

return -1; 
x = y/sb->foo; //potential division-by-zero 

return 0- 



) 




Soln: let FS generate its own disks 



EXE: Execution generated Executions [Cadar 

and Engler, SPIN'05] [Cadar et al Stanford TR2006-1] 

■ Run code on symbolic input, initial value = "anything" 

■ As code observes input, it tells us values input can be 

■ At conditional branch that uses symbolic input, explore 
both 

■ On true branch, add constraint input satisfies check 

■ On false that it does not 

■ exit() or error: solve constraints for input. 

To find FS security holes, set disk symbolic 




Key enabler: STP constraint solver 



Handles: All of C (except floating point) 

■ Memory, arrays, pointers, updates, bit- 
operations. 

■ Full bit- level accurate precision. No 
approximations. 

■ One caveat: **p, where p is symbolic. 

Written by David Dill and Vijay Ganesh. 

■ Destroy's previous CVCL system 

■ 10-1000+x faster, 6x smaller. 

■ Much simpler, more robust 



A galactic view 




Symbolic 
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Test Cases 



Concrete Disks 



Path Selection 




Symbolic 
Execution 
Runtime 
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Test Case Generation 



Test Case Checking 



EXE-cc instrumented 




Outline 



How EXE works 

Apply EXE to Linux file systems 

Results 




The toy example 



int fake_mount(char* disk) { 
struct super_block *sb = disk; 
if(sb->magic != 0xEF53) //hard to pass using random 

return -1; 
// sb->foo Is unsigned, therefore >= 
if(sb->foo > 8192) 

return -1; 
x = y/sb->foo; //potential division-by-zero 

return 0: 



} 




Concrete v.s. symbolic execution 



Concrete: sb->magic = 0xEF53, sb->foo = 9000 




x=y/sb->foo 
i 

return 



return -1 



return -1 




Concrete v.s. symbolic execution 



Symbolic: sb->magic and sb->foo unconstrained 




return -1 



sb->magic != 0xEF53 



return -1 



x=y/sb->foo 



I 



sb->magic " 0xEF53 
sb->f oo > 8192 



return 



sb->magic — OxEF53 
sb->foo< 8192 

y == v/ch-vfnn 




The toy example: instrumentation 



int fake_mount(char* disk) { 
struct super_block *sb = disk; 



if(sb->magic != 0xEF53) 
return -1; 



if(sb->foo > 8192) 
return -1; 



y = y/sh-ifofl; 



int f ake_mount_exe(char* disk) { 
struct super_block *sb = disk; 
if(fork() == child) { 

constraint(sb-> magic != 0xEF53); 

return -1; 
} else 

constraint(sb-> magic == 0xEF53); 

jf(fork() == child) { 

constraint(sb->foo > 8192); 

return -1; 
} else 

constraint(sb->foo <= 8192); 

check_symbolic_div_by_zero(sb->foo); 
Y=y/sh->foo; 




How to use EXE 



Mark disk blocks as symbolic 

■ void make_symbolic(void* disk_block, unsigned 
size) 

Compile with EXE-cc (based on CIL) 

■ Insert checks around every expression: if operands 
all concrete, run as normal. Otherwise, add as 
constraint 

■ Insert fork when symbolic could cause multiple acts 

Run: forks at each decision point. 

■ When path terminates, solve constraints and 
generate disk images 

■ Terminates when: (1) exit, (2) crash, (3) error 

Rerun concrete through uninstrumented Linux 




Why generate disks and rerun? 



Ease of diagnosis. No false positive 

One disk, check many versions 

Increases path coverage, helps 
correctness testing 




Mixed execution 



Too many symbolic var, too many constraints 
■* constraint solver dies 

Mixed execution: don't run everything 
symbolically 

■ Example: x = y+z; 

■ if y, z both concrete, run as in uninstrumented 

■ Otherwise set "x == y + z", record x = symbolic. 

Small set of symbolic values 

■ disk blocks (make_symbolic) and derived 

Result: most code runs concretely, small slice 
deals w/ symbolics, small # of constraints 

■ Perhaps why worked on Linux mounts, sym on 
demand 




Symbolic checks 



int fake_mount(char* disk) { 
struct super_block *sb = disk; 



if(sb->magic != OxEF53) 
return -1; 



if(sb->foo > 8192) 
return -1; 



y m y/sh->fflfl; 



int f ake_mount_exe(char* disk) { 
struct super_block *sb = disk; 
if(fork() == child) { 

constraint(sb-> magic != OxEF53); 

return -1; 
} else 

constraint(sb-> magic == OxEF53); 

jf(fork() == child) { 

constraint(sb->foo > 8192); 

return -1; 

} else 
cheotefitrri^^ 



Y=y/sh->foo; 




Symbolic checks 

Key: Symbolic reasons about many 
possible values simultaneously. Concrete 
about just current ones (e.g. Purify). 

Symbolic checks: 

■ When reach dangerous op, EXE checks if any 
input exists that could cause blow up. 

■ Builtin: x/0, x%0, NULL deref, mem overflow, 
arithmetic overflow, symbolic assertion 




Check symbolic div-by-0: x/y, y symbolic 



Found 2 bugs in ext2, copied to ext3 



void check_sym_div_by_zero (y) { 
if (query (y==0) == satisfiable) 
if(fork() == child) { 

constraint(y != 0); 
return; 
} else { 

constraint(y ==0); 
solve_and_generate_disk(); 
error ("divided by 0!") 

3 




More on EXE ([CCS'06]) 



Handling C constructs 

■ Casts: untyped memory 
. Bitfield 

■ Symbolic pointer, array index: disjunctions 

Limitations 

■ Constraint solving NP 

■ Uninstrumented functions 

■ Symbolic double dereference: concretize 

■ Symbolic loop: heuristic search 




Outline 



■ How EXE works 

■ Apply EXE to Linux file systems 
D ■ Results 




Results 

■ Checked ext2, ext3, and JFS mounts 

■ Ext2: four bugs. 

■ One buffer overflow ■*• read and write 
arbitrary kernel memory (next slide) 

■ Two div/mod by 

■ One kernel crash 

■ Ext3: four bugs (copied from ext2) 

■ JFS: one NULL pointer dereference 

■ Extremely easy-to-diagnose: just 
mount! 




Simplified: ext2 r/w kernel memory 



ini" pyt? n\/gn-flrnA/(in+ hlnrk uncinngrl rnnrvt-) 



block is symbolic ' > 

if(block < lower_bound 
block + count can overflow ^> 1 1 fblock+counrt > higher bound) 



and becomes negative! return 

Pass block to bar "i ^count- -) 

bar(block++); 

} 

void bar(int block) { 

block_group is symbolic ^> n B = power of 2 

int blockaroup = (block-A)/B; 

block can be large! 



Symbolic read off bound ., , .. . Q 

7 //array length is 8 

Symbolic write off bound >=>... = array [block_group] 

array[block_group] = ... 




Related Work 

■ FS testing 

■ Mostly stress test for functionality bugs 

. Linux ISO9660 FS handling flaw, Mar 2005 
(http://lwn.net/Articles/128365/) 

■ Static analysis 

■ Model checking 

■ Symbolic model checking 

■ Input generation 

■ Using symbolic execution to generate testcases 




BPF, Linux packet filters 



"We'll never find bugs in that" 

■ heavily audited, well written open source 

Mark filter & packet as symbolic. 

■ Symbolic = turn check into generator 

■ Safe filter check: generates all valid filters of 
length N. 

■ BPF Interpreter: will produce all valid filter 
programs that pass check of length N. 

■ Filter on message: generates all packets that 
accept, reject. 




Results: BPF, trivial exploit. 



ii Check that memory operations only uses valid addresses. 
// => Check forgets LDX,STX! 

if( (BPF_CLASS(p->code) == BPF-ST || (BPFjCLASS(p->code) == BPF.LD && 
(p->code & OxeO) == BPF-MEM}) && p->k >= BPF-MEMWORDS ) 
retina 0; 



case BPF_LDX |BPF_MEM: 

X = mem[pc— >k]: continue; 

case BPF.STX: 

mem[pc— >k] = X: continue; 




Linux Filter 



vjGriGrStGQ llltGr! // other filters that cause this error . . . 

// => BPF_LD|BPF_B BPFJND 
// => BPF_LD|BPF_H | BPFJND 
s[0] .code = B PF.L D | B PF.B B PF_ A B S : 
s[0].k = Ox/fffffffUL: 

s[1].code = BPF-RET; 
s[1].k = OxfffffffOUL: 



iline void t skb_header.pointer( struct skJbuff *skb n iul offset, hit leu. 
int hie n = skbjieadlen(skb); 
if (offset + len <= hlen) 

re turn skb->data + offset: 




Conclusion [Oakland'06, CCS'06] 



Automatic all-path execution, all-value 
checking 

■ Make input symbolic. 

■ Run code. 

■ If operation concrete, do it. 

■ If symbolic, track constraints. 

■ Generate concrete solution at end (or on way), 
feed back to code. 

■ Finds bugs in real code. 

■ Zero false positives. 




Exponential forking? 

■ Only fork on symbolic branch 

■ Mixed execution: to reduce # of symbolic var, don't 
run everything symbolically. Mix concrete execution 
and symbolic execution 

■ Example: x = y+z; 

■ if y, z both concrete, run as in uninstrumented 

■ Otherwise set "x == y + z", record x = symbolic. 

■ Small set of symbolic values 

■ disk blocks (make_symbolic) and derived 

■ Result: most code runs concretely, small slice deals 
w/ symbolics, small # of constraints 

■ Perhaps why worked on Linux mounts, sym on demand 



